Skip to main content

Interoperability

Interoperability is the ability of two systems to exchange information and use it. The second half is what makes it hard. Moving bytes is a solved problem; ensuring the receiving system means the same thing by them is not.


Integration is not interoperability​

These words are used interchangeably and should not be.

TermMeansScales?
IntegrationMaking two specific systems work together, by whatever meansNo — cost grows with every pair
InteroperabilitySystems working together because they conform to shared, published specificationsYes — cost grows with each system, once
Information exchangeThe act of moving data between organisationsDepends on the above
Health information exchangeThe organisation, infrastructure and governance that make exchange routine across an ecosystemIt is the mechanism that makes it scale

A bespoke nightly CSV between an EMR and the HMIS is an integration. Both systems conforming to a published FHIR implementation guide is interoperability. The first is faster to deliver and is why most ecosystems have forty of them.

The practical test: if a third system arrives, does it reuse the work? If not, you built an integration.


The four levels​

Each level depends on the ones below it. Skipping a level does not remove the requirement; it defers it to the point where data is being used, which is the most expensive place to discover it.

┌──────────────────────────────────────────────────┐
4 │ Organisational │
│ Legal basis, governance, agreements, funding, │
│ operating model, trust │
├──────────────────────────────────────────────────┤
3 │ Semantic │
│ Shared meaning — terminology, value sets, maps, │
│ information models, identity resolution │
├──────────────────────────────────────────────────┤
2 │ Syntactic │
│ Shared structure — FHIR profiles, HL7 v2 │
│ message structure, CDA templates, schemas │
├──────────────────────────────────────────────────┤
1 │ Technical / foundational │
│ Connectivity, transport, authentication, │
│ encoding — HTTPS, TCP, JSON, XML │
└──────────────────────────────────────────────────┘

1. Technical​

Two systems can establish a connection and move bytes reliably and securely.

Concerns: transport (HTTPS, MLLP for HL7 v2, SFTP for batch), authentication of the caller, encryption in transit, retry and idempotency, rate limiting, availability.

Mechanisms: REST APIs, GraphQL, gRPC, webhooks, message queues, event streams. See integration engines.

Usually the easy level — and the one that gets all the attention, because it is the one engineers can finish.

2. Syntactic​

The receiver can parse the message and locate the fields.

Concerns: format (JSON, XML, NDJSON, CSV, HL7 v2 pipe-delimited), schema conformance, versioning, required versus optional elements, character encoding and internationalisation.

Mechanisms: FHIR profiles, HL7 v2 message structures, CDA templates, JSON Schema, validators.

Where conformance testing lives. "It's FHIR" is a technical-level claim; "it validates against the national IG" is a syntactic-level one.

3. Semantic​

The receiver understands what the data means, well enough to act on it or count it.

Concerns:

  • Terminology — is the diagnosis coded with SNOMED CT, ICD, or a local list? See terminology services.
  • Value sets and binding strength — which codes are permitted where
  • Units — UCUM, and the difference between mg/dL and mmol/L
  • Identity — is this the same patient, the same facility, the same clinician? See registries
  • Information model — does "encounter" mean the same thing on both sides?
  • Context — negation, uncertainty, family history, planned versus performed. A code for "myocardial infarction" attached to a family history section means something entirely different from the same code on a problem list.

This is the level that determines whether the exchange was worth building. Data that arrives, parses and cannot be pooled has cost money and delivered nothing.

4. Organisational​

The exchange is permitted, funded, operated and trusted.

Concerns: legal basis for sharing, data sharing agreements, consent model, governance bodies, conformance certification, incident response, service levels, who pays for the shared components, and what happens when a participant fails to meet its obligations.

Mechanisms: trust frameworks, participation agreements, an architecture review board, national policy. See governance.

This is the level that stops most national programmes, and it cannot be solved by procurement. A technically perfect exchange with no legal basis for sharing does not run.


A diagnostic​

When an exchange is not delivering value, work down the levels:

SymptomLevelLikely cause
Messages time out or fail intermittently1Network, auth, retry design, capacity
Messages rejected as malformed2Profile mismatch, version drift, missing required elements
Messages arrive but reports don't change3Terminology not mapped, identity unresolved, model mismatch
Everything works technically but nobody uses it4No legal basis, no incentive, no operating model, no trust
The pilot worked and the rollout stalled4The pilot had a champion; the ecosystem has governance gaps

The instinct is to debug at level 1 because that is where the logs are. The problem is usually at level 3 or 4.


Cost of the levels​

Rough proportions from national programmes, and the reason budgets are consistently wrong:

Effort actually required Effort typically budgeted
──────────────────────── ─────────────────────────
Technical 15% Technical 60%
Syntactic 20% Syntactic 25%
Semantic 35% Semantic 10%
Organisational 30% Organisational 5%

Terminology mapping and governance are the work. Everything else is comparatively tractable.


In this section​


References​